00100	Protocol sketch for four SPOT-like concept formation programs
00200	
00300	U represents the user, S the system, in the following  dialog excerpts.
00400	
00500	1. SPOT with only a MUST  subset
00600		I shall describe the dialog, rather than exhibiting it.
00700	There are two alternatives, each involving small changes from the
00800	dialog used to write SPOT.  
00900		First, we assume that at some point the system itself suggests
01000	structuring the relations into three subsets, based on applying its
01100	knowledge of contradiction to the domain of concept formation.  At this
01200	point, the user might simply say:
01300	U: What are the three lists?
01400	S: (i) Relations which MUST be present, which are necessary for this choice
01500	  (ii) Relations which MUSTNOT be present, whose absence is necessary for
01600		me to pick this identification
01700	 (iii) Relations which MAY be present, but whose presence or absence does
01800		not affect my choice of identification
01900	U: Do not bother keeping a MUSTNOT list.
02000	S: Yes or no:  "I am merging the concepts of MUSTNOT and MAY lists, into one
02100		NOTMUST list, which will hold the union of the MUSTNOT and the
02200		MAY lists, anything not on the MUST list."
02300	U: Yes.
02400	
02500		The second alternative assumes that the user agrees (perhaps is not
02600	even consulted, or perhaps didn't decide until after) to the  tripartite
02700	decision above was made.  The new dialog sample takes place later, when the
02800	system is discussing the transfers of relations which must be done to update
02900	the models.
03000		.
03100		.
03200		.
03300	S: When the guess is incorrect, I have two possible actions: 
03400		(1) Find a relation present in the scene but absent from all 3
03500	sets of relations in the incorrectly-chosen model; transfer this relation
03600	from NONEXISTENCE to the MUSTNOT list of the model.
03700		(2) Find a relation absent in the scene but present in the MAY
03800	list of the incorrectly-identified model; transfer the relation from
03900	the MAY list to the MUST list of the model.
04000	
04100		Please type in some ordered subset of {1,2} to direct me. I suggest
04200	1,2    	or 2,1.   I suggest against the empty set.
04300	
04400	U: 2
04500	
04600		Notice that these both have the flavor of adding but a few bits
04700	of directional control on a very smart system.  To do any more work than
04800	this (on such a small change) would hurt the automaticity  of the system.
04900	
05000	
05100	2. SPOT with only a MUSTNOT subset
05200	
05300	I shan't bore you with a repetition of (1).  This is quite similar!
05400	
05500	
05600	3. SPOT with an ALWAYS-WAS subset
05700	
05800	S:	Hi.  What can I do for you?
05900	U: 	Write a concept formation program. Here is SPOT, which you have
06000		just written.  Get psyched up and we will begin adding to it.
06100	S:	OK, I am in a state of full awareness re the writing of SPOT.
06200		What would you like to do to it?
06300	U:	One thing, I notice that some of the transfers between the MAY,
06400		MUST, and MUSNT lists cause past examples to work improperly.
06500		Find me an example of this phenomenon.
06600	S:	If  we must choose between two features to transfer from MAY to
06700		MUST, only one is correct, we choose the incorrect one, later
06800		discover our mistake, put it back onto the MAY list.  Then that
06900		first example would again be misidentified.
07000	U:	Any other cases?
07100	S:	When we choose to move a feature from MAY to MUST, we might have
07200		already seen a scene in which it did NOT occur. So this would
07300		immediately cause the old scene to be misidentified. 
07400	U:	How could you fix this up?
07500	S:	(i) By keeping around all the old scenes, using them to check new
07600		changes. (ii) By tagging each MAY feature to indicate whether it
07700		has ever not appeared in this type of scene. (iii) By creating a
07800		fourth list, ALWAYS:WAS, to keep separate those MAY candidates
07900		which could reliably be transferred to MUST.
08000	U:	How would the last two ideas work?
08100	S:	When a concept is first encountered, no features are tagged. When a
08200		new instance is seen, all relations in the symmetric difference of
08300		the existing MAY set and the new set of relations is tagged.
08400		The next case is analogous, with tagging/notagging equivalent to
08500		position on the MAY/ALWAYS list.
08600	U:	Which is better?
08700	S:	(i) is the quickest but uses the most space, (ii) is most easily
08800		implemented and optimized, (iii) is easy to implement and the most
08900		symmetric. In view of future expansions, I suggest (iii).
09000	U:	OK, do it.
09100	S:	<sound of grinding, shredding, looping, etc. in the background> OK.
09200		What next?
09300	
09400	
09500	4. SPOT with high-level concepts built out of low-level ones
09600	
09700	U: What use do you make of the contents of the relations read in?
09800	S: I use them for matching purposes only; no examination of contents is done
09900	U: I want you to do such an examination from now on
10000	S: Explain further
10100	U: Examine the relations carefully just after accepting or rejecting a model
10200	S: OK, I have located those two places in the synthesized code. Go on.
10300	U: After rejecting, examine the first element of each relation which failed
10400		because of its presence on the MUST list of the model but absence
10500		in the scene. If a scene relation is itself a known concept, replace
10600		it by all its MUST relations and repeat the matching attempt. Also,
10700		after accepting, examine each relation as well, and do a similar
10800		replacing and retesting.
10900	S: I understand.   Warning: this could lead to an infinite regress:
11000		Concept A is defined in terms of B which is defined in terms
11100		of A ...          Suggestion: set a depth level.
11200	U: No, the infinite regress won't occur.  
11300	S: I have my doubts. I will set the depth level anyway, dynamically,
11400		to 2**(number of relations on all other lists put together).
11500	U: <grumbling noises>
11600	
11700	
11800	5. SPOT with reordering of the relations (graph-matching)
11900	
12000	
12100	U:	I want a scene to be correctly identified even if its objects have
12200		a new order and new names.
12300	S:	Unclear. Here is my idea of arch: (arch (a b c) (MUST (supports a c)
12400		(supports b c))  (MUSNT (touches a b)) (MAY (green a)(block c))).
12500		What kind of altered scene should be identified as an arch, now?
12600	U:	(? (z y x) (supports x z)(supports y z)(green x)(blue y))
12700	S:	I can see many ways to do this.   (i) We may examine and then use
12800	        the object list to determine a mapping which is applied to the rest
12900		of the scene.  (ii) All scenes are transformed into canonical form
13000		when read in, i.e., as if they had all had objects (a b c ...)
13100	        This means the mapping is a simple permutation always.
13200		Is one of these what you want?
13300	U:	Compare the two for me, please.
13400	S:	No, I don't want to.
13500	
13600		Obviously, either choice is fine.